home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv2.zip / SDKV2N14.TXT < prev    next >
Text File  |  1993-06-23  |  9KB  |  205 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. GUS Programmer's Digest     Wed Jun 16 00:07     Volume 2: Issue  14  
  7.  
  8. Today's Topics:
  9.                   Gravis/FORTE - Please read this!!!
  10.                            Turbo Pascal SDK
  11.  
  12. Standard Info:
  13.     - Meta-info about the GUS can be found at the end of the Digest.
  14.     - Before you ask a question, please READ THE FAQ.
  15.  
  16. ----------------------------------------------------------------------
  17.  
  18. Date: Tue, 15 Jun 93 10:20:12 EDT
  19. From: davidm@opl.com
  20. Subject: Gravis/FORTE - Please read this!!!
  21. Message-ID: <AFC9AA9E-AA9E0001@woodstock.opl.com>
  22.  
  23. (Hi, gus-sdk readers, this is primarily intended for...)
  24.  
  25. Gravis/FORTE,
  26.  
  27. I have been working with the low level SDK (version 2.01) for a few nights
  28. now and I have discovered a couple of points which you neglected to put in
  29. the low level SDK code and/or documentation.  I describe them here and
  30. follow their descriptions with some suggestions for their correction and/or 
  31. improvement.  At the end I ask a few quesitons and offer some praise.
  32.  
  33. POINT 1
  34. -------
  35. The first point is what was causing the problem I had with looping and wave 
  36. table interrupts.  If I set up a voice with looping and WITHOUT interrupts,
  37. everything behaved as expected.  If I set up a voice with looping and WITH
  38. interrupts, the voice would play from start to end and then stop - no
  39. looping.  This was driving me crazy (for quite some time, I might add) until 
  40. I looked in IRQ.C and saw the following...
  41.  
  42. if (!(wave_ignore & voice_bit))
  43. {
  44.     UltraStopVoice(voice);
  45.     wave_ignore |= voice_bit;
  46.  
  47.     /* Call waveform processing function.... */
  48.     _gf1_data.wavetable_func(voice);
  49. }
  50.  
  51. EUREKA!!!  UltraStopVoice gets called before my callback function!!!
  52.  
  53. You neglect to mention this fact in the SDK documentation (thank you, NOT!)
  54. or at least I couldn't find reference to it.
  55.  
  56.  
  57.  
  58. The ramifications of this fact are that (more often than not, IMHO) the
  59. first thing that anyone's wave table callback function will do is call
  60. UltraGoVoice.  Since UltraGoVoice needs a "mode" passed to it, the mode
  61. bits for every voice that may generate a wave table IRQ must be stored in
  62. a global array.
  63.  
  64. (I haven't gotten to it yet, but from what I saw in IRQ.C, I suspect that
  65. volume ramping will have the same kind of situation.)
  66.  
  67. POINT 2
  68. -------
  69. The second thing that irks me has to do with the rollover bit.  It seems to
  70. me that this bit has more to do with controlling a voice than it has to do
  71. with controlling a volume ramp.  It seems that the number of voice control
  72. bits didn't fit into an 8 bit register so one bit got stuck into an ununsed
  73. position of the volume ramp control register.  This is borne out by the fact
  74. that in GF1HWARE.H most of the bits for the volume ramp control are labelled
  75. VL_<something>, but the rollover bit is labelled VC_ROLLOVER (the VC_ prefix
  76. corresponds to the prefixes of the other voice control bits).  I have no 
  77. problem with this bit "relocation".  The one gripe I do have about this 
  78. topic is that there is no clean way to manipulate this bit, using the 
  79. functions provided in the SDK.  As far as I can tell, the only way to 
  80. influence this bit, using the functions provided in the SDK, is to use 
  81. UltraRampVolume.  It seems to me that it would be rather difficult, using
  82. the functions provided in the SDK, to alter the rollover bit without
  83. affecting what very well may be an active volume ramp.  Since this bit plays
  84. such an important part in a ping-pong buffer implementation, it seems like
  85. a gross oversight to leave this functionality out of the SDK.
  86.  
  87. SUGGESTIONS
  88. -----------
  89. Regarding the first point, it's not clear to me why UltraStopVoice needs to
  90. be called before calling the callback function.  In any event, you should
  91. either change the SDK to not call it or at least *MENTION* that it does in 
  92. fact get called before the callback.  Why does this call get made anyway?
  93.  
  94. Regarding the second point, looking in VOCSTART.C it becomes apparent that
  95. the two least significant bits of the "mode" byte get stripped in 
  96. UltraGoVoice before it is written to the voice control register.  It seems 
  97. that one of those bits could be used as a rollover flag that gets written to
  98. the the rollover bit in the voice's volume ramp control register.  This would
  99. give the ability to control ALL of a voice's control bits in the "mode" byte
  100. that is passed to  UltraGoVoice (and UltraPrimeVoice and UltraStartVoice).
  101.  
  102. QUESTIONS
  103. ---------
  104. 1) Why does UltraStopVoice need to be called before the wave table callback
  105.    function is called?
  106.  
  107. 2) Assuming UltraStopVoice needs to be called before the wave table callback
  108.    function is called, is a global array the best way to keep track of the
  109.    control bits for the various voices that may want to call UltraGoVoice in
  110.    the wave table callback funtion?
  111.  
  112.  
  113.  
  114. 3) Is there a way, using the functions provided in the SDK, to read the
  115.    current mode bits of a voice?
  116.  
  117. 4) What do you think the chances are for an improved UltraGoVoice that 
  118.    accepts a rollover flag in one of the two least significant bits of the
  119.    "mode" byte?
  120.  
  121. 5) Until such an improved UltraGoVoice becomes available, can you provide
  122.    example code that will allow the examination and modification of the
  123.    rollover bit WITHOUT affecting any volume ramp that may be in progress?
  124.    Here are the prototypes of the functions I would like... 
  125.  
  126.    // returns the current state of the rollover bit for voice <voice_num>
  127.    int UltraGetRollover( int voice_num);
  128.    
  129.    // sets the state of the rollover bit for voice <voice_num> to 1 if
  130.    // <state> is non-zero or to 0 if <state> is zero
  131.    // returns the previous state of the rollover bit
  132.    int UltraSetRollover( int voice_num, int state);
  133.  
  134.    // toggles the state of the rollover bit for voice <voice_num>
  135.    // returns the previous state of the rollover bit for voice <voice_num>
  136.    int UltraToggleRollover( int voice_num);
  137.  
  138.    Well, if you give me the first two, I can come up with the third one :-)
  139.  
  140. PRAISE
  141. ------
  142. Please take the above comments seriously, but not too harshly.  I love my 
  143. GUS!!!  And (as I wrote on my registration card) I bought one primarily 
  144. because it had such AWESOME support (i.e. SDK) available over the Internet 
  145. and on BBS's.  I know, I get what I pay for, but you (Gravis and FORTE) get
  146. what you pay for, too.  I haven't charged you anything (would've if I
  147. could've) for all the time I spent finding these "quirks" which are 
  148. affecting (or will affect) countless others developing code for this 
  149. FANTASTIC sound card.
  150.  
  151. Keep up the good work,
  152. Dave
  153.  
  154. David MacMahon
  155. Systems Administrator
  156. davidm@opl.com
  157.  
  158. ------------------------------
  159.  
  160. Date: Tue, 15 Jun 93 13:53 EDT
  161. From: "Matthew E. Bernold" <MEB117@PSUVM.PSU.EDU>
  162. Subject: Turbo Pascal SDK
  163. Message-ID: <9306151752.AA10814@orca.es.com>
  164.  
  165. I made the mistake of posting my first announcement on a Friday night, and I
  166.  
  167.  
  168. am not sure how many people missed it because of it being delivered on a
  169. Saturday, so I'll post one more time.
  170.  
  171. I am currently in the process of making a straight translation of the GUS
  172. SDK version 2.01 from C to Turbo Pascal (Version 6).  As of right now, I have
  173. been able to translate all commands that do not have to do with IRQ and DMA
  174. functions, and I want to release an alpha test version of the SDK to a few
  175. people.
  176.  
  177. If anyone is interested in helping me test this SDK, please note me by Friday
  178. or so, as I should be mailing out the alpha by then.  Also, if there is
  179. someone who is familiar with programming IRQ or DMA in Turbo Pascal/C, I
  180. could use some help with translating some of the more involved functions in
  181. the SDK.
  182.  
  183. Thank you,
  184.  
  185.        Matthew E. Bernold             MEB117@PSUVM.PSU.EDU
  186.          <<APOCALYPSE>>                  meb@wilbur.cac.psu.edu
  187.  
  188. ------------------------------
  189.  
  190. End of GUS Programmer's Digest V2 #14
  191. *************************************
  192.  
  193. To post to tomorrow's digest:               <gus-sdk%itchy@dsd.es.com>
  194. To (un)subscribe or get help:       <gus-sdk-request%itchy@dsd.es.com>
  195. To contact a human (last resort):     <gus-sdk-owner%itchy@dsd.es.com>
  196.  
  197. FTP sites:         archive.epas.utoronto.ca         pub/pc/ultrasound
  198.                    wuarchive.wustl.edu       systems/msdos/ultrasound
  199. Hints:
  200.       - Get the FAQ from the FTP sites or the request server.
  201.       - Mail to <gus-sdk-request%itchy@dsd.es.com> for info about
  202.     other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)
  203.  
  204.  
  205.